Usenet 1993 July

home *** CD-ROM | disk | FTP | other *** search

/ Usenet 1993 July / InfoMagic USENET CD-ROM July 1993.ISO / sources / std_unix / RFC.001 < prev next >

Wrap

Internet Message Format | 1987-11-26 | 26.2 KB

From: std-unix%ut-sally.UUCP@SALLY.UTEXAS.EDU (Moderator, John Quarterman) Newsgroups: mod.std.unix Subject: RFC.001 Timezones Message-Id: <5350@ut-sally.UUCP> Organization: IEEE 1003 Portable Operating System for Computer Environments Committee Date: 17 Jul 86 22:46:09 GMT Draft-9: TZ.RFC.001 This is the first of a series of five articles about timezones. It is posted to make public previous discussions in this area and not to stir up the issue again. The time is propitious because the U.S. President has just signed a new daylight savings time law. The other four articles of this series form RFC.001, which was submitted to the IEEE 1003.1 Working Group in Florence on 18 April 1986. The set of articles is as follows: V6N29 RFC.001 Timezones: this article (not part of RFC.001 proper). V6N30 RFC.001 Summary of mod.std.unix Volume 5 by the moderator. V6N31 RFC.001 Timezone Interface (reposting of V5N65) by Robert Elz. V6N32 RFC.001 Timezone Examples (from V5N57) by Arthur Olson. (just the examples from the last few pages, not the whole article). V6N33 RFC.001 Time Zone Proposal by jsq. The last item has the same intent as the Elz article but is in a form which should be usable as an actual proposal. It may be submitted as such soon. There was another RFC (from HP) which solved all the same problems but by a slightly different mechanism. Perhaps its author would like to post it? Volume-Number: Volume 6, Number 29 From: std-unix%ut-sally.UUCP@SALLY.UTEXAS.EDU (Moderator, John Quarterman) Newsgroups: mod.std.unix Subject: RFC.001 Summary of mod.std.unix Volume 5. Message-Id: <5351@ut-sally.UUCP> Organization: IEEE 1003 Portable Operating System for Computer Environments Committee Date: 17 Jul 86 22:53:24 GMT Draft-9: TZ.RFC.001 Summary of time zone discussion (and other material) in mod.std.unix Volume 5. The time zone discussion was in response to a request in P1003 Appendix A.3. The numbers in parentheses like (N3) correspond to article number within Volume 5. The *problem* was first stated by Mark Horton (N3). * GMT/local time disparities exist in the real world: Internal system time must be GMT (N11) as used by make (N6), etc. Many log files are in local time, e.g., RCS, SCCS (N15). Users want to see dates displayed in local time (N3). Some parameter files are in local time, such as UUCP's L.sys (N5), crontab (N13), and at (N69). Conversions should work for dates from at least 1 Jan 1970 (N26) (for ls, SCCS, RCS, other logs) to near future (L.sys, crontab, at) (N65). * Network/dialup logistics: Synchronization of networked hosts also requires internal GMT (N17). Some network-related logs should perhaps be in GMT (N10). Users may be in different timezones than hosts (N7, N14, N13). Client workstations may be in different time zones than servers (N63). * Politics in the real world sets time zones: There are many standard one-hour-from GMT timezones (STs); some of them may have different names in different countries. There are many Dalight Savings Times (DSTs) related to STs, usually by adding one hour. These DSTs differ even within the same ST (N63). Double daylight savings time is sometimes used (N62, N58). Even daylight losing time is plausible (N51, N65). Sometimes the DST offset from ST is not integral hours (N28). There are local times which are not DSTs and also not integral hours from GMT (N19, N13). Offset precision of minutes is necessary (N19) but seconds not (N63). ST may change at any time (China switching to several zones, N62). DST may change at any time and with little notice (Australia, N65). or for brief periods (U.S. presidential elections, N27). Timezone names may conflict (Bering Strait Time/British Summer Time) or be non-alphabetic (N54, N48). Some *deficiencies* of existing implementations (N3). * V7/BSD: inefficiency of system call. * System III/V: initialization and security (N3, N66, N63, N4, N50); one hour precision is not enough (N63). * both: DST tables wired into kernel or library, respectively. Proposed *solutions*. * Early proposals by Kenneth Almquist (N24) and Bob Devine (N47) were very useful for discussion but flawed. * Interface as proposed by Robert Elz (N65): Three conversions sufficient: GMT, default local, user's local (N55). Timezone format left to the implementation. Timezone in environment allowed. Default initialization and security provided. (A routine to translate timezone name to offset possibly useful (N67).) Proposed *implementation* by Arthur Olsen (N68,N57) since posted to mod.sources. * Inspired Elz's interface and is sufficient for it (N65). * Jack Jansen's implementation would also fit Elz's interface (N65). * Miscellaneous implementation criteria: Should not be shell-specific (N49). Should not put timezone offset in u-area (N22, N21, N20). Efficiency requirements (N66): conversion of present time fast for logging, of near past pretty fast for "ls -l", of distant past may be slow. * A particular implementation may be broad or narrow, depending on the intended market (N65, N63). Far *future* considerations. * Machines are currently considered stationary (N60). * Days may not be of 24 hours (N58). * Announcement of info-futures list (N59). Other topics in mod.std.unix Volume 5, with numbers of the corresponding sections of the IEEE 1003.1 Trial Use Standard: setuid and environment clearing (N39, N31) 3.1.2. setuid switching (N46, N45, N44, N43) 4.2.2. ex-directory (N12, N8) directory umask 5.3.3, 5.6.1. motivation (N35, N23, N22) objections (N34, N33, N25) proposals to use .cshrc (N30, N35, N29) clarifications: not per cwd (N38); process umask remains (N40) philosophy (N42, N37) solution (N41) The IEEE 1003 Committee and mod.std.unix (N36, N33, N35) Draft 6 (N2) meetings: Denver (N18); Florence (N71). administrativia (N1, N30). guest moderator (N71, N70). End of summary of mod.std.unix Volume 5. Volume-Number: Volume 6, Number 30 From: std-unix%ut-sally.UUCP@SALLY.UTEXAS.EDU (Moderator, John Quarterman) Newsgroups: mod.std.unix Subject: RFC.001 Timezone Interface Message-Id: <5352@ut-sally.UUCP> Organization: IEEE 1003 Portable Operating System for Computer Environments Committee Date: 17 Jul 86 23:03:01 GMT Draft-9: TZ.RFC.001 [ This is part of RFC.001 and is a reposting of V5N65. -mod ] Date: 02 Mar 86 05:47:32 +1100 (Sun) From: Robert Elz <munnari!kre@SEISMO.CSS.GOV> >Subject: localtime(), ctime() and timezones It seems to me that this discussion is getting a bit overblown, as far as P1003 is concerned, it doesn't really seem to be as difficult or complex as some people are making out. So, I'm going to propose something that could be inserted into P1003 (with the obvious extra definitions that I'm going to leave out on the assumption that everyone knows what they are, like the definition of a "struct tm"). In some words of other, it would go like this (with hopefully a lot of cleaning up of the typography to get rid of quotes and things like that where I would really prefer to use italics or bold): Implementations shall provide the following functions: struct tm *gmttime(t) time_t *t; struct tm *localtime(t) time_t *t; int settz(p) char *p; char *asctime(tp) struct tm *tp; char *ctime(t) time_t *t; gmttime: converts the time_t "*t" to a "struct tm" representing the same time (in Universal Co-ordinated Time). (waffle about the returned value being in a static area, etc, goes here). localtime: converts the time_t "*t" to a "struct tm" representing the given time adjusted to represent some local time difference. "local time" will be specified by a call to "settz", if no such call has preceded the call to localtime(), localtime() will call "settz(getenv("TZ"));". Implementors should note that for any defined past time (from midnight January 1, 1970 until the time the call is made) the local time returned should be accurate (taking into account the effects of daylight saving, if any). For future times, the local time returned should be as likely to be accurate as current projections of future timezone rules and daylight saving time changes allow. settz: enables users to specify the local time conversion to be used by localtime. The string is an implementation specific representation of the timezone offset desired, with 2 special cases.. The null pointer (t == (char *)0) will always select the appropriate local time offset for the host executing the call. A null string (t != (char *)0 && *t == '\0') will select no local time transformations (making localtime() equivalent to gmttime()). Implementations should provide, and document, some mechanism to allow users to select another timezone. This mechanism is beyond the scope of the standard. Implementors should, if possible, allow users to define their own timezones, and not restrict them to use one of some standard set. If settz is called with an unrecognisable argument, the effect is implementation defined. (Users might expect any of three "reasonable"? actions could be taken here -- use GMT, use local time, or use local time in the area where the implementation was performed). settz returns 0 if the timezone selected could be obtained, and -1 otherwise. settz can be called as many times as needed, each call affects future calls of localtime, until another call to settz. acstime: returns a 25 character string representing the time specified by "*tp". The format of the string is ... (you all know it). ctime: is defined to be "asctime(localtime(t))". ................... Notes: this is (about) the right level of detail for the standard. There is no need to specify what the form of the argument to settz() is. This enables things like the Sys V "EST5EDT" string, and Arthur Olson's (elsie!ado) "localtime" "Eastern" etc, to all be used with impunity - the implementor gets to choose whatever is appropriate to him - just provided that he can satisfy the needs of his customers (implementors who provide no means of getting daylight saving right in the Southern hemisphere can probably expect not to sell many copies there - but that's their choice). In particular - this discourages programmers from writing programs which "know" what the local time should be - there's no reason at all why a program should ever need to do more than select GMT, host local time, or a user specified time zone. (nb: while localtime uses the TZ environment variable in cases where the program has made no call to settz(), there's nothing to stop a program getting the argument to settz() from anywhere it pleases, including from several different environment variables if it chooses, and needs to operate in several timezones, or from an external configuration file, or wherever is appropriate). This works for existing programs (in general) - localtime() performs the required call to settz() the first time it is called (directly or via ctime()). There's no need to worry about who sets TZ, if its not set, getenv("TZ") will return (char *)0 and settz() will then use the appropriate local time for the host. How settz() gets that information is an implementation matter. The security problems (people faking local time for programs that expect it to be host local time, by setting TZ before running the program) can easily solved by causing those (comparatively few) programs to do "settz((char *)0)" before their first call to localtime(). What's missing: So far here there is no mention of the "timezone name". None of the standard mechanisms is really adequate here. The V7 (and 4.xbsd) "timezone" function is clearly inadequate (although 4.2 bsd allows users to set the environment variable TZNAME to anything they like) since there can clearly be several possible names for the same offset, and "timezone" has no way to discover which one is wanted. Requiring the name to resice in the environment somewhere (Sys V) is also inadequate (there are too many problems about making sure it is set in all the right places). Arthur Olson's scheme causes "localtime" to set a global variable "tz_abbr" to the correct string name for the timezone just used. I can't think of any cases where anything more than this is needed, but it is less flexible then "timezone()" and it would require programs that currently call timezone() to have to be altered. (He also has his version of "ctime" (but not "asctime") include the timezone in its output - I doubt if that is feasible for P1003, too many existing programs know what every byte in the returned string from ctime() contains.) I solicit suggestions for what to do here - one might be to retain "timezone" but not require that it be capable of returning anything except the zone name corresponding to the last call of localtime() - then with ado's implementation it could simply ignore its arguments and return tz_abbr - I suspect that would satisfy all existing uses (and the ones it doesn't are quite likely not to work in general anyway). Opinions? There's also no discussion of how this relates to processes and images. Not because there's anything doubtful here, but just because the necessary words take a lot of space. (informally, "the first call to localtime" is intended to be "the first after the program is exec'd, ignoring any fork()'s it may have since performed, as long as there has been no subsequent exec). Getting this kind of thing right is essential for a standatds document, its not essential here. ................... A justification for all this ... Today, just about 2 1/2 hours ago (it's early on a Sun morning as I write this) the daylight saving rules changed in at least 2 Australian states (no-one really seems very sure of what happened, or really why). The politicians gave us less than a month's warning that it was coming (and the month was February, which isn't a long month...). If there's anyone who doesn't believe that some form of dynamic timezone setting is required, they're welcome to come to Australia and suffer our local politicians (this isn't the first time: a couple of years ago New South Wales decided to extend daylight saving for a month to try and save on power bills - the amount of notice given was about the same - at that time, at least one local site decided to scrap running on GMT and run on localtime (ala VMS) instead. They're still doing that, I think, and suffering because of it). I'm extremely grateful that Arthur Olson decided to try an implementation, and donate it to the community - he made the task of converting things here much easier than it otherwise would have been. His implementation meets the above specs (in fact, it inspired them...), and will work for all the contorted exampes that people have been proposing (multiple shifts in a year, multi-hour saving, even daylight wasting). But note - there's no need for the standard to require this generality, market pressures will do that - all the standard needs to do is supply a suitable interface. Arthur Olson's implementation proves that the above reccomendation is implementable (munnari is running his code, in libc, right now) and effecient enough. [ Your last sentence gives the reason that I've encouraged discussions of implementations in the newsgroup: it's good to know that a proposed standard is implementable and handles actual cases. But you're right, of course, that the P1003 standard doesn't need implementation details. -mod ] Jack Jansen's (mcvax!jack) somewhat similar, but slightly different scheme would probably work just as well. Bob Devine's (hao!asgb!devine) "I don't think its needed" attitude can also fit the standard - if he's right then he's probably going to have a very fast localtime() which will serve him well. If he's wrong, then he's not going to get many customers. That's good - the more the better - that gives us users (or us system implementors perhaps) a wide choice of methods. Robert Elz kre%munnari.oz@seismo.css.gov seismo!munnari!kre Volume-Number: Volume 6, Number 31 From: std-unix%ut-sally.UUCP@SALLY.UTEXAS.EDU (Moderator, John Quarterman) Newsgroups: mod.std.unix Subject: RFC.001 Timezone Examples Message-Id: <5353@ut-sally.UUCP> Organization: IEEE 1003 Portable Operating System for Computer Environments Committee Date: 17 Jul 86 23:06:37 GMT Draft-9: TZ.RFC.001 [ This is part of RFC.001 and is a reposting of some examples from V5N57. Note that the current version of Arthur Olsen's implementation is to be found in the mod.sources archives, not in mod.std.unix. This posting is intended merely to illustrate the variety of possible timezones. -mod ] echo tzcomp.8 1>&2 cat >tzcomp.8 <<'End of tzcomp.8' .TH TZCOMP 8 .SH NAME tzcomp \- time zone compiler .SH SYNOPSIS .B tzcomp [ .B \-d directory ] filename ... .SH DESCRIPTION .I Tzcomp reads text from the file(s) named on the command line and creates the time zone information files specified in this input. If a .I filename is .BR ` - ', the standard input is read. .PP This option is available: .TP .B \-d directory Create time zone information files in the named directory rather than in the standard directory named below. .PP A sharp characters (#) in the input introduces a comment which extends to the end of the line the sharp character appears on. Any line which is blank (after comment stripping) is ignored. Non-blank lines are expected to be of one of three types: rule lines, zone lines, and link lines. .PP A rule line has the form .nf .B .ti +.5i .ta \w'Rule 'u +\w'MostNA 'u +\w'FROM 'u +\w'1973 'u +\w'TYPE 'u +\w'Apr 'u +\w'lastSun 'u +\w'2:00 'u +\w'SAVE 'u .sp Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S .sp For example: .ti +.5i .sp Rule MostNA 1969 1973 - Apr lastSun 2:00 1:00 D .sp .fi The fields that make up a rule line are: .TP .B NAME Gives the (arbitrary) name of the set of rules this rule is part of. .TP .B FROM Gives the first year in which the rule applies. .TP .B TO Gives the last year in which the rule applies. The word .RB ` only ' may be used to repeat the value of the .B FROM field. .TP .B TYPE Gives the type of year in which the year applies. If .B TYPE is .B "-" then the rule is taken to apply in all years between .B FROM and .B TO inclusive. If .B TYPE is something else, then the command .B .ti +.5i years from to type .br is executed with arguments .IR from , .IR to , and .IR type taken from the rule line; the rule is taken to apply only in those years printed by the .I years command. The distributed .I years command is a shell script that can handle year types .B uspres (United States presidential election years) and .B nonpres (all other years); other year types may be added by changing the script. .TP .B IN Names the month in which the rule takes effect. Month names may be abbreviated. .TP .B ON Gives the day on which the rule takes effect. Recognized forms include: .nf .in +.5i .sp .ta \w'lastSun 'u 5 the fifth of the month lastSun the last Sunday in the month lastMon the last Monday in the month Sun>=8 first Sunday on or after the eighth Sun<=25 last Sunday on or before the 25th .fi .in -.5i .sp Names of days of the week may be abbreviated or spelled out in full. Note that there must be no spaces within the .B ON field (or within any other field). .TP .B AT Gives the time of day at which the rule takes affect. Recognized forms include: .nf .in +.5i .sp .ta \w'1:28:13 'u 2 time in hours 2:00 time in hours and minutes 15:00 24-hour format time (for times after noon) 1:28:14 time in hours, minutes, and seconds .fi .in -.5i .sp .TP .B SAVE Gives the amount of time to be added to local standard time when the rule is in effect. This field has the same format as the .B AT field. .TP .B LETTER/S Gives the "variable part" (for example, the 'S' or 'D' in "EST" or "EDT") of time zone abbreviations to be used when this rule is in effect. If this field is .B "-", the variable part is null. .PP A zone line has the form .sp .nf .ti +.5i .ta \w'Zone 'u +\w'Eastern 'u +\w'GMTOFF 'u +\w'MostNA 'u Zone NAME GMTOFF RULES FORMAT .sp For example: .sp .ti +.5i Zone Eastern -5:00 MostNA E%sT .sp .fi The fields that make up a zone line are: .TP .B NAME The name of the time zone. This is the name used in creating the time zone information file for the zone. .TP .B GMTOFF The amount of time to add to GMT to get standard time in this zone. This field has the same format as the .B AT and .B SAVE fields of rule lines; begin the field with a minus sign if time must be subtracted from GMT. .TP .B RULES The name of the rule(s) that apply in the time zone. If this field contains .B "-" then standard time always applies in the time zone. .TP .B FORMAT The format for time zone abbreviations in this time zone. The pairs of characters .B "%s" is used to show where the "variable part" of the time zone abbreviation goes. .PP A link line has the form .sp .nf .ti +.5i .ta \w'Link 'u +\w'LINK-FROM 'u Link LINK-FROM LINK-TO .sp For example: .sp .ti +.5i Link Eastern EST5EDT .sp .fi The .B LINK-FROM field should appear as the .B NAME field in some zone line; the .B LINK-TO field is used as an alternate name for that zone. .PP Lines may appear in any order in the input. .SH EXAMPLE [Since a sample time zone file appears in the shell archive, this section has been omitted.] .SH FILES /etc/tzdir standard directory used for created files .SH "SEE ALSO" settz(3), tzfile(5) .. @(#)tzcomp.8 1.4 End of tzcomp.8 echo tzinfo 1>&2 cat >tzinfo <<'End of tzinfo' # @(#)tzinfo 1.5 # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule MostNA 1969 1973 - Apr lastSun 2:00 1:00 D Rule MostNA 1969 1973 - Oct lastSun 2:00 0 S Rule MostNA 1974 only - Jan 6 2:00 1:00 D Rule MostNA 1974 only - Nov 24 2:00 0 S Rule MostNA 1975 only - Feb 23 2:00 1:00 D Rule MostNA 1975 only - Oct 26 2:00 0 S Rule MostNA 1976 2037 - Apr lastSun 2:00 1:00 D Rule MostNA 1976 2037 - Oct lastSun 2:00 0 S # Almost surely wrong: # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Oz-Eur 1969 1973 - Apr lastSun 2:00 1:00 S Rule Oz-Eur 1969 1973 - Oct lastSun 2:00 0 - Rule Oz-Eur 1974 only - Jan 6 2:00 1:00 S Rule Oz-Eur 1974 only - Nov 24 2:00 0 - Rule Oz-Eur 1975 only - Feb 23 2:00 1:00 S Rule Oz-Eur 1975 only - Oct 26 2:00 0 - Rule Oz-Eur 1976 2037 - Apr lastSun 2:00 1:00 S Rule Oz-Eur 1976 2037 - Oct lastSun 2:00 0 - # New names # Zone NAME GMTOFF RULES FORMAT Zone Atlantic -4:00 MostNA A%sT Zone Eastern -5:00 MostNA E%sT Zone Central -6:00 MostNA C%sT Zone Mountain -7:00 MostNA M%sT Zone Pacific -8:00 MostNA P%sT Zone Yukon -9:00 MostNA Y%sT Zone Hawaiian -10:00 MostNA H%sT Zone Newfoundland -3:30 - NST Zone Japan 9:00 - JST Zone WET 0 Oz-Eur WE%sT Zone MET 1 Oz-Eur ME%sT Zone EET 2 Oz-Eur EE%sT Zone AEST 10:00 Oz-Eur AES%sT Zone ACST 9:30 Oz-Eur ACS%sT Zone AWST 8:00 - AWST # No Daylight Saving here? # # A settz("") uses the code's built-in GMT without going to disk to get # the information. Still, we want things to work if somebody does a # settz("GMT"), so. . . # Zone GMT 0 - GMT # Old names # Link LINK-FROM LINK-TO Link Eastern EST5EDT Link Central CST6CDT Link Mountain MST7MDT Link Pacific PST8PDT # "Pacific Presidential Election Time" is being contemplated in Congress # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Twilite 1969 1973 - Apr lastSun 2:00 1:00 D Rule Twilite 1969 1973 - Oct lastSun 2:00 0 S Rule Twilite 1974 only - Jan 6 2:00 1:00 D Rule Twilite 1974 only - Nov 24 2:00 0 S Rule Twilite 1975 only - Feb 23 2:00 1:00 D Rule Twilite 1975 only - Oct 26 2:00 0 S Rule Twilite 1976 2037 - Apr lastSun 2:00 1:00 D Rule Twilite 1976 1987 - Oct lastSun 2:00 0 S Rule Twilite 1988 2037 uspres Oct lastSun 2:00 1:00 PE Rule Twilite 1988 2037 uspres Nov Sun>=7 2:00 0 S Rule Twilite 1988 2037 nonpres Oct lastSun 2:00 0 S # Zone NAME GMTOFF RULES FORMAT Zone New-Pacific -8:00 Twilite P%sT # Next really belongs in a separate file Link Eastern localtime End of tzinfo exit -- UUCP: ..decvax!seismo!elsie!ado ARPA: elsie!ado@seismo.ARPA DEC, VAX and Elsie are Digital Equipment and Borden trademarks Volume-Number: Volume 6, Number 32 From: std-unix%ut-sally.UUCP@SALLY.UTEXAS.EDU (Moderator, John Quarterman) Newsgroups: mod.std.unix Subject: RFC.001 Timezone Proposal Message-Id: <5354@ut-sally.UUCP> Organization: IEEE 1003 Portable Operating System for Computer Environments Committee Date: 17 Jul 86 23:10:14 GMT Draft-9: TZ.RFC.001 RFC.001 Proposal Form, 18 April 1986, submitted by John S. Quarterman. Time Zone Proposal based on work by Robert Elz and Arthur Olsen. Add 4.5.3 and 4.5.4 to the standard and perhaps also document Arthur Olsen's implementation in an Appendix. 4.5.3 Set Local Time Conversion Function: settz() 4.5.3.1 Synopsis int settz(p) char *p; 4.5.3.2 Description The settz() function determines the conversion from GMT of the local times returned by localtime() and ctime(). When called with a null pointer argument (p==0), settz shall select the appropriate local time conversion for the location of the host machine on which the call is executed. When called with a null string (p!=0 && *p=='\0'), settz shall select no conversion for localtime, making localtime() and gmtime() equivalent and ctime() and asctime(gmtime()) equivalent. When called with a non-null string (p!=0 && *p!='\0'), settz may set the conversion according to that string. The format of the string and the conversions it may specify are implementation specific. If an implementation accepts non-null string arguments to settz, the implementation should allow users to define their own conversions rather than restricting conversions to a standard set. If settz is called with a string for which the implementation can not find a conversion, settz shall return -1, but the conversion it sets is implementation defined and may be one of GMT, the executing machine's local time, or local time for the area where the implementation was performed. 4.5.3.3 Returns Upon successful completion, settz() returns 0, otherwise -1. 4.5.4 Get Local Time Functions: localtime(), ctime() 4.5.4.1 Synopsis [ as in X3J11 ] 4.5.4.2 Description [ as in X3J11, plus: ] The local time conversion is specified by a call on settz(). If localtime() or ctime() is called and settz() has not been called since the last exec(), the localtime() or ctime() call shall call settz(getenv("TZ")) before performing the local time conversion. The local time conversion should be accurate for all times from the base time of the time() function up to the time the call is made. Future times should be converted as accurately as possible with available political information. Daylight savings time should be taken into account in both cases. 4.5.4.3 Returns [as in X3J11 ] 4.5.4.4 Errors [as in X3J11 ] Volume-Number: Volume 6, Number 33